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Abstract—In this paper we introduce Timed Moore Au- 
tomata, a specification formalism which is used in industrial 
train control applications for specifying the real-time behavior 
of cooperating reactive software components. We define an 
operational semantics for the sequential components (units) 
with an abstraction of time that is suitable for checking timeout 
behavior of these units. A model checking algorithm for livelock 
detection is presented, and two alternative methods of test 
case/test data generation techniques are introduced. The first 
one is based on Kripke structures as used in explicit model 
checking, while the second method does not require an explicit 
representation but relies on SAT solving techniques. 


Keywords-Timed Moore Automata, model-based testing, 
model checking, livelocks 


I. INTRODUCTION 
A. Motivation 


In this paper we introduce Timed Moore Automata 
(TMA), a syntactic and semantic extension of classical 
Moore Automata [6]. TMA are used in industrial train 
control applications for specifying the real-time behavior 
of cooperating reactive software components. While the 
description formalism has been designed by railway control 
system suppliers, our contribution consists in the elaboration 
of test automation and model checking methods for TMA 
specifications. To this end, we define an operational seman- 
tics for the sequential components (units) with an abstraction 
of time that is suitable for checking timeout behavior of these 
units: The application software only distinguishes between 
running and elapsed timers, but does not have a notion of 
the real time span passing between setting a timer and the 
associated elapsed-timer event. As a consequence, control 
decisions involving several timers have to be programmed 
in a way such that any of the timers may elapse first, 
though, in reality, only a restricted number of elapsed- 
timer sequences may be possible. Intuitively speaking, we 
introduce a simulation semantics for the Timed Automata, 
so that every computation sequence possible in reality is also 
a valid computation according to the TMA semantics, but 
not necessarily vice versa. 

Based on this semantics, two alternative fully automated 
model-based unit test generation algorithm are presented. 
Both algorithms guarantee full requirements coverage and 
MC/DC coverage on code level, provided that the code 
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is derived from the model according to a well-defined 
pattern. As a consequence, the tests are also sufficient to 
be used for checking the results of an automated code 
generator. The algorithms are inspired by techniques from 
explicit and bounded model checking, respectively, using 
Kripke structures or, alternatively, SAT solving techniques 
to elaborate the concrete test data. Since the success of 
model-based testing depends on the models’ quality we 
advocate an approach where model verification and model- 
based testing are performed in an integrated tool set. Indeed, 
the similarities between data structures and algorithms used 
in model checking and test data generation suggest that 
this is also a promising approach from the perspective of 
tool construction. For the formalism under consideration the 
main specification problems observed during practical appli- 
cations consisted in livelocks. We have therefore integrated 
automated livelock detection with test data generation. The 
verification is based on the classical Kripke structures used 
in explicit model checking, because the limited size of the 
specification models and the Boolean nature of their input 
and output interfaces suggests this approach. We sketch 
briefly, how this technique is also used for large-scale models 
on an abstracted level. 


B. Related work 


At least in theory, tests against automata-based formalisms 
can be made exhaustive as shown, for example, in [1], [9]. 
In practice, however, this would lead to an infeasible number 
of tests, even for the units under test we are considering in 
this paper. Our approach therefore focuses on the generation 
of useful test cases in the sense that they are sufficient 
to establish compliance with the applicable safety-related 
standards such as [2]. The application of SAT solving to test 
case generation also plays an important role for structural 
test generation based on software code. There, due to the 
more complex data types usually needed for applications 
more general than the ones described here, SAT solving is 
embedded into a Satisfiability Modulo Theory framework 
allowing to handle arithmetic expressions over integers and 
floats, as well as pointer expressions [7]. In [5] a timed 
state machine formalism is considered where timers are 
represented on a less abstract level than in our paper. While 
in [5] only atomic input symbols are admitted, our approach 


handles Boolean input vectors and Boolean transition guards 
referring to vector component values. 


C. Overview 


Section II introduces the specification formalism Timed 
Moore Automata and section HI defines its operational 
semantics. In section IV Kripke structures over TMA are 
described and a livelock checking algorithm is presented. 
Based on these explicit model checking techniques, the 
first collection of test generation algorithms is presented in 
section V. As an alternative, section VI presents algorithms 
based on SAT solving, such that the explicit unfolding of 
the Kripke state space becomes unnecessary. Section VII 
presents performance measurements for a collection of TMA 
used in the railway control domain. Finally, section VIII 
gives a conclusion and an outlook on ongoing work. There 
we also motivate the utilization of Kripke structures for more 
powerful modeling formalisms. 


II. FORMAL DEFINITION OF TIMED MOORE AUTOMATA 


TMA process input symbols € = (&,...,&) € B” 
and produce outputs n = (m,.-.,%m) E€ B™. Just as in 
classical Moore Automata, output values only depend on 
the current control state 1 € LOC the automaton resides 
in. Classical Moore Automata, however, process their inputs 
in discrete steps like a synchronous device, and their state 
transition function is total. In contrast to this, TMA inputs 
are interpreted as state vectors and processed in run-to- 
completion mode: For a given input € several consecutive 
transitions may be taken if they are enabled by €. As a 
consequence, TMA transition relations are not total, and a 
sequence of consecutive transitions triggered by some input 
€ leads to a stable control state l if no transition leaving l 
is enabled by €. A cycle of consecutive enabled transitions 
represents a livelock situation which is to be avoided because 
it corresponds to an unwanted endless loop in the TMA 
implementation. 

Additionally TMA extend classical Moore Automata by 
admitting the definition of a set of Boolean timer activation 
and timer status variables: when entering a control state, 
timer activation variables T may be set to 1, leading to the 
activation of associated timers in the runtime environment 
of the automaton’s implementation. With each activation 
variable T' a status variable t is associated and may be 
referenced in the Boolean expressions of guard conditions: 
t = 1 indicates that the timer has not yet elapsed, and t = 0 
indicates that the timer has expired. As a result, TMS operate 
on an abstracted notion of real time; it is only possible to 
check whether a pre-defined time duration has passed or 
not, but the value of this duration in concrete time units is 
unknown on TMA level. A stable control state l is left as 
soon as a transition leaving l becomes enabled, either by 
a change in the input vector or by a timer status changing 


from “activated to “elapsed”. These intuitive concepts are 
formalized in this section. 


A. Abstract Syntax 


A Timed Moore Automaton consists of a tuple 
(LOC, loco, VARin, VARout, VARta, VARs, Lout, Lia, R), 
where LOC is the set of locations, loco € LOC is the 
initial location, VA Rin is the set of input variables, VA Rout 
is the set of output variables, VARzq is the set of timer 
activation variables, VARs is the set of timer status 
variables. Function Lout : LOC — {loco} —> 2V4Reut 
labels each location with the entry action on output 
variables. Lig : LOC — {loco} — (VARia > B) 
labels each location with its entry action on zero or more 
timers. R = LOC — > (N 4> (GUARD x LOC)) 
is a function associating each location with its outgoing 
guarded transitions: suppose R(lọ) = 7 for some 
function T N ~ (GUARD x LOC). Then for 
each n € dom 7 the image T(n) specifies a transition 
with source location lo. If r(n) = (gn,ln) then ln 
is the target location of r(n) and gn is its guard 
condition. The argument n defines the transition’s priority. 
Guards are conjunctions of possibly negated atoms from 
VARin U VARs; more formally GUARD = NG xG, 
where NG = G = P(VAR;, U VAR;,,) denote the 
sets of negated and non-negated Boolean atoms from 
VARi, U VARis, respectively. We use the mapping 
B : VARia —> VAR;, to associate timer activation 
variables and their corresponding timer status variables. 


B. Static Semantics 


Some consistency conditions have to be imposed on the 
syntax in order to identify well-formed TMA. (1) The sym- 
bol sets VARin, VARout, VARta, VARts are pairwise dis- 
joint. (2) No transition may have the initial location as target: 
If r = R(l), n € dom 7 and T(n) = (g, ln), then ln # loco. 
(3) The initial location has just one unguarded emanating 
transition: Sl € LOC —{loco} : R(loco) = {1 => (Ø, 2,])}. 
(4) The priorities of transitions emanating from a given loca- 
tion always consist of consecutive numbers, starting with 1: 
Vl € LOC — {loco} : Im € No: dom R(l) = {1,...,m}. 
For m = 0 the domain is empty, this characterizes termi- 
nal locations. (3) Contradicting guard conditions are not 
allowed: If T(n) = (gn,ln) and gn = (Nn, Gn), then 
Nn N Gn = Ø, i.e., an atom may not appear both negated 
and unnegated in the guard condition. 


C. Abstract and concrete syntax — example 


Fig. 1 shows an example of the concrete graphical TMA 
syntax. The initial location loco is denoted by ®, all other 
locations are represented by rounded boxes which are la- 
beled by their entry actions. For entry actions on output 
variables, all variables not listed are implicitly set to 0. For 
timer activations, only the specified actions are performed. 


Figure 1. Timed Moore automaton with VA Rin = {a,b,c}, VARout = 
{X,Y, Z}, VARta = {T}, VARis = {t}. 


In location loc,, for example, output X is set to 1 on entry, 
and Y to 0. Additionally, timer T is activated. If only one 
transition leaves a location the priority may be omitted, it is 
implicitly set to 1. Negated atoms a are denoted by !a. The 
abstract syntax of the TMA shown in Fig. | is 


Lot = {loc = {X = 1,Y = 0,Z = 0}, 

locg => {X = 0,Y = 0,Z = 1h} 

locg3 = {X = 0,Y = 1,7 OF} 
{loci œ {T = 1}, locg + Ø, locz + Ø} 
{loco + {1 => (Ø, Ø, loc1)}, 

locı œ> {1 ({a}, {c}, locs), 

21> ({a}, {b}, loc2)}, 

locy +4 {11> (2; {a}, locs)}} 

locz + {1 ({t}, Ø, locy)}} 
Tt 


Lia = 


D 
II 


III. SEMANTICS OF TIMED MOORE AUTOMATA 


We define the operational semantics of TMA to be the 
state transition system (S, So, T) with state space S, set of 
initial states Sọ C S' and transition relation T C S x S. 


A. Variable valuations and state space 


The state space S' consists of variable valuations for in- 
puts, outputs and timers. In addition it is useful to introduce 
an auxiliary Boolean variable symbol stable indicating that 
the TMA is in a stable state, i. e. that no further transitions 
are possible before either some time passes until the next 
timer elapses or a change in the input vector enables new 
transitions. States which are not stable are called transient. 


We model stable as an auxiliary output. Let 


Xis = VA Ris m 
Zout = VARout U {stable} — 
D = VA Ria E 


denote the set of associated valuation functions. With these 
definitions the state space is given by 


S C LOC x Sin X Mts X Mout X Yta 


B. Initial state 


The initial state of a TMA has loco as initial location. All 
outputs are set to 0, all timers in an inactive state, but the 
inputs may have arbitrary values. Moreover, the initial state 
is unstable since we have exactly one unguarded transition 
leaving loco: 


So = {loco} X Dn X (VARs = {0}) x 
(V ARout U {stable} — {0}) x (VARta — {0}) 


C. Guard valuations and action valuations 


We use a fresh symbol £ for locations and write ø (£) =der 
l for states o = (l, Cin, Ots, Cout, Cta) E S. For symbols x € 
VARin U VARs U VARout U VARia we define o(2) =4ef 
Oin(x) if x € VARin, o(@) =aet Ots(x) if x € VARs, 
a(x) =def Cout(£) if x € VARout and o(£) =4ef Cta(x) if 
LE VA Ria. 

We write o = «x if and only if o(x) = 1 and o j x 
if and only if o(a) = 0. For a transition R(o(£))(n),n € 
dom R(a(¢)), we use the abbreviation o = R(o(0))(n) if 
R(a())(n) = ((N,G),U) for some target location I’ and 
the transition guard (NV, G) evaluates to 1, that is, all atoms 
a in the guard condition evaluate to 0 if they appear negated 
(i. e., a € N), and evaluate to 1 if they appear unnegated 
(i. e., a € G). More formally, 


oF R(o(E))(n) Saef 

(N,G) € GUARD,!’ € LOC: 
R(a()(n) = (W, G), 1) A 
(Vae N:o F-a)A(VWbEG:a0- 5) 


Ww 


For an entry action Lout(l) on output variables in a 
location l, we write 


oF Lout(l) Saet (2) = 1A 
(Va € VARout : (0 H z & Lou(l)(x) = 1)) 


For an entry action La (l) on timer activations o = Lia (l) 
is defined in an analogous way. 


D. Transition relation 


Given state S and transition relation T C S x S let 


— — F / £ / / 
C= (l, Cin, Ots, Cout, Cta) and o' = (l , Oin Cts Tout Cta) 


in the paragraphs below. The elements of transition relation 


T are characterized by a predicate T (ø, 0’) in the sense that 
(a,0') ET = T(o,0’). Predicate T(o,0’) is defined by 


T(o,0') inv(c) A inv(a’) A 
Ruleg(c, 0’) A Rules(c,0’) A 


Rule4(0, 0’) 


=def 


where the invariant inv(o) and the rules Rule;(c, 0’) are 
introduced in the paragraphs to follow. 

(1) A state is stable if all guard conditions of leaving tran- 
sitions evaluate to false. This is formalized by the following 
invariant, where o € S with o = (l, Cin, Cts, Cout, Ota): 


inv(o) =qef 
(o = stable) = 
(Vn € dom R(o(£)) : o KF R(o(£))(n)) 


(2) Locations, outputs and timer activations remain un- 
changed if the state is stable. Moreover, elapsed timers do 
not change their states. 


Rulez (9, a’) =def 
(o H stable) > 
o' (L) = a(l) A Olut = Tout \ Sta = Cta N 
(Vt € VARs: 0o Et => Kt) 


(3) In transient states inputs remain stable and time does 
not pass, that is, all timer states remain unchanged. 


Rulez (0, 0’) =aet 
(o j stable) > oin 


= 1— 
= Oin \ Ois = Tts 


(4) If one or more transitions leaving the current location 
have guard conditions evaluating to 1, then the one with 
the best priority (1 is best) is taken. The TMA proceeds 
to the transition’s target location, and the valuations of the 
output variables change according to the entry action of the 
target location. A timer activation during an entry action sets 
the associated timer status to 1. Resetting an active timer 
by means of its activation variable automatically resets the 
associated timer status. 


Rulea(o, 0’) =aet 
dn € dom R(a(2£)) : (o H R(a(2))(n) A 
Ym € {1,...,n— 1}: o - R(o(0))(m))) > 
a'(£) = m2(R(o(L))(n)) A 
a H Loull (O) Ao’ H Litala’ (0) A 
(Vu € dom Lial’ (8): 
Litala’ (£))(u) = 1 > cts = B(u)) A 
(Vu € dom Lial’ (8): 
Litala" (6) (u) = 0 > o7, E B(u)) A 
(Vu € VARia — dom Lia (a'(@)) : 
a'(u) =a(u)) A 
(Vu € VARia — dom Lia(a'(é)) : 
o'(B(u)) = o(B(u))) 


In this rule, 72 denotes the projection on the second compo- 
nent, that is, the target location, of the transition R(a(£))(n). 


~ 


~ 


Recall that @ maps timer activation variables onto their 
corresponding timer status variables. 

Lemma I; Let M a Timed Moore Automaton and o a 
state of M. Then, if o is transient, it has exactly one post- 
State: 


(o & stable) = (HoE S | T(c,0’)}| =1) 


Proof. If o is transient then inv(c) implies that there exists 
a transition R(o(£))(n) leaving location o(£) whose guard 
condition is enabled, that is, o = R(a(¢))(n). Without 
loss of generality let n > 1 the smallest number satisfying 
a H} R(o(€))(n). Application of Rule, now implies the 
existence of a post-state o’ and uniquely determines o’(@), 
Olut and o. For (o,o) to be in T the pair also has 
to satisfy Rules(c,o’), and this determines o/,, and o},. 
oa’ (stable) is uniquely determined from the fact that inv(a’) 
must hold and o’(¢) is already fixed. This shows that one 
and only one g’ exists such that 7 (ø, o’) holds. 
Lemma 2: Let M a Timed Moore Automaton with tran- 
sition relation T C S x S. Then T is total, that is, every 
state o € S has at least one successor state o’ € S such that 
T(a,0’). 
Proof. From Lemma 1 we know that every transient state has 
a post-state in T. Now let ø € S be stable. Then Rules does 
not apply and neither does Rule, since inv(c) implies that 
the premise of Rule, is not fulfilled. Now it is easy to see 
that there exists at least one (stable or transient) post-state 
a’ satisfying inv(o’) and Ruleg(c, a’). As a consequence, 
T(o,0’) holds and therefore (o, o’) € T. 


IV. MODEL CHECKING FOR TIMED MOORE AUTOMATA 


This chapter introduces the algorithms used to perform 
explicit model checking of CTL properties on Timed Moore 
automata. We use Kripke structures to that end and closely 
follow [3]. Since these algorithms and the underlying theory 
are well understood and documented in the literature, we will 
focus on results that are specific for TMA. 


A. Construction of Kripke structures 


Every Timed Moore Automaton 


M = (LOC, loco, VARin, VARout, VARta, VARts, 
Lout, Lita, R) 


with operational semantics given by transition system 
TS(M) = (S, So, T) as explained in Section III gives rise 
to a labeling function L : S —> QAP where AP is the set 
of atomic proposition over M. Intuitively speaking, L(c) is 
the set of all propositions that are true in state o. Now all 
variables of M have Boolean type; moreover, every location 
£L € LOC may be identified with the Boolean atom £ € B, 
o } £ stating that “when in state o, M resides in location 
L”. As a consequence, the atomic propositions over M are 


AP =aef LOC U VARin U VARout U 
VARia U VAR: U {stable} 


function constructSuccessors(in o : S): P(S) 
let o = (L, Oin, Ots, Oout, Ota); 
if (o - stable) 
newStates = {o' = (l, oln, Ots, Tout Tra) E S | 
l =LA lut = Cout N Ota = Cta A 
(Vt € VARs : 704s(t) > 704, (t))} 
ret = calcStable(new States); 
else 
l = neatLocation(o); 
o1 = (l', Cin, Ots, Cout, Ota ); 
o2 = applyLocation(o1); 
ret = calcStable({o2}); 
endif 
constructSuccessors = ret; 
end 


Figure 2. Function constructSuccessors constructs the successor set for 
a given state o. 


and L is determined by L(o) =4ef {x € AP | o — x} for 
all ø € S. This construction introduces a Kripke structure 
K(M) over M by setting K(M) =aer (S, So, T, L). 

Constructing the Kripke structure in an explicit way 
requires to obtain an explicit representation of the transition 
relation T C S x S. The standard algorithm is a breadth-first 
search starting with the set of initial states So and calculating 
transitions by means of a next-state function. 

Algorithm constructSuccessors(a) (Fig. 2) explains how 
to compute the sets of successor states {o’ € S | T(c,0’)} 
of a given state o, as required in algorithm constructKripke. 
Its behavior is dictated by the given system state’s running 
state: If o is a stable state, then the set of successor 
states will consist of multiple states with modified inputs 
and timer states. The set of system states with identical 
location, identical output valuation, identical timer activation 
valuation, free input valuation and modified timer status 
valuation is initially collected in set newStates. Recall, 
that when in a stable state, a timer status may only be 
modified from 1 (running) to 0 (elapsed), but not vice versa. 
Function calcStable (Fig. 3) modifies the resulting states’ 
stable valuation depending on whether the modifications 
have enables a transition emanating from location l. 

If the source system state o is not stable we employ func- 
tion nextLocation to determine the location of a successor 
system state. An intermediate system state o1 is constructed 
from initial system state ø by simply changing the associated 
location. Function applyLocation (Fig. 5) applies changes 
necessary due to entry actions associated with new location 
i’. Finally, function calcStable (Fig. 3) is called to determine 
whether the resulting successor state is stable. 

Function calcStable (Fig. 3) loops over all states within a 
given set and determines, whether each state can transition 


function calcStable(in states : P(S)) : P(S) 
ret = ©; 
forall o € states do 
ret = ret U (o @ {stable œ 7canTransition(c)}); 
enddo 
calcStable = ret; 
end 


Figure 3. Function calcStable reassigns stable valuations for a given set 
of system states. 


function canTransition(in o : S): B 
ret = false; prio = 1; 
let o = (l, Cin, Ots, Cout, Cta); 
while (prio € dom R(l)) do 
if (o | R(l)(prio)) 
ret = true; break; 


endif 
prio = prio + 1; 
enddo 
can Transition = ret; 
end 


Figure 4. Function canTransition determines whether a state o can 
transition to another location. 


to a new location. This is determined by using function 
canTransition (Fig. 4). Each state’s stable valuation is 
modified accordingly. 

Function can Transition (Fig. 4) loops over all transitions 
emanating from a location | associated with given system 
state o in order of priority. If any transition is enabled 
within o, the function returns true, false otherwise. Function 
nextLocation is nearly identical to function can Transition 
(Fig. 4) except that for a given system state o and asso- 
ciated location l, it will return the target location for the 
enabled transition emanating from / with highest priority. 
If no transition emanating from l is enabled, its behavior 
is undefined. However, since function neztLocation is only 
called for transient states, this poses no problem. 

For a given system state ø with associated location l, 
function applyLocation (Fig. 5) modifies valuation functions 
Cout» Sta and oy, according to entry actions associated with 
l. With the exception of stable, all outputs are reassigned 
according to labeling function Lout. All timer activations 
within Lta(l) are reflected in Cta and ots. For all timer vari- 
ables, that are not in the domain of Lta(l), timer activation 
valuations and corresponding timer status valuations remain 
unchanged. 

Since states are valuation functions of Boolean symbols 
this suggests to encode them as bit-vectors indicating which 
symbols evaluate to true or false in o. Then the labeling 


function applyLocation(in a: S): S 
let o = (l, Oin, Ots, Fouts Ota); 
o’ =<0; 
forall x in VAR,,; do 
a =0' {x (x € Loull}; 
enddo 
forall t in dom Lia(l)do 
of = 0' @ {t > Liall)(t)}: 
o! =o! & {B(t) > Lra(l)()} 
enddo 
end 


Figure 5. Function applyLocation modifies valuations of a given state 
o according to entry actions associated with its location. 


function L is obtained in a trivial way by collecting in each 
state the symbols whose associated bits have value 1. 

The size of the Kripke structures used in this paper 
were reduced considerably by means of the delayed non- 
determinism technique introduced in [8]: The explicit state 
representation for valuations o € S was extended by means 
of “Don’t Care” bits on input valuations Gin indicating 
whether an input is used in a guard condition of the current 
control state o(@). If an input a is not referenced in any of 
a(€)’s guards then the unfolding of its possible values may 
be delayed, which is marked by setting a don’t care bit for 
a in o(£). Only before entering a new location depending 
on a the unfolding is performed, now leading to different 
states for each a value. This technique reduces the states and 
paths of the Kripke structure in a considerable way and was 
therefore implemented in our tool box. Indeed, the largest 
of the TMA used for performance evaluation as described 
later in section VII could not be handled by constructing the 
corresponding Kripke structure without employing delayed 
nondeterminism. 


B. Checking CTL properties 


Given a Kripke structure as introduced above, arbitrary 
model properties expressible in Computation Tree Logic 
CTL may be checked, using the well known algorithms of 
explicit model checking [3]. We will now show in more de- 
tail how model checking with respect to livelock properties 
can be performed for TMA in an optimized manner. 


C. Live-lock checking of TMA 


A live-lock occurs when a TMA executes a cycle of 
transient system states. This cycle will never terminate since 
the TMA is deterministic and the system will never react to 
changing inputs, because those are only considered when 
in a stable state. Formally speaking, a live-lock occurs 
when there exists a cycle oo Oy > ... > On T0 
such that co is reachable from some initial state in So, 
the cycle is consistent with the transition relation, Vi € 


{1,...,n} : T(oi-1,0;) A T(on,00), and each state is 
transient, i. e., Vi € {0,...,n}: stable ¢ L(o;). Expressed 
as a CTL property, live-locks may occur in reachable states 
co fulfilling co = EG(-stable), or, equivalently, in TMA 
satisfying EF(EG(-stable)). Conversely, for establishing 
live-lock freedom, the negation of the previous formula has 
to be proven: 


livelockFree =aerp AG(AF(stable)) 


In order to check this property, it must first be transformed 
into a semantically equivalent form containing only opera- 
tors =, A, V, EX, EG and EU: 


AG(AF(stable)) 
< AG(AEG(-stable)) 
© AEF(EG(-stable)) 
= AE(true U (EG(-stable))) 


In general, checking formulas of the type EG@ involves 
the expensive calculation of (non-trivial) strongly connected 
components [3, p. 36]. Therefore the following theorem is 
helpful to increase the efficiency of the live-lock checking 
algorithm, since the formulas to be checked alternatively in 
the case of TMA can be handled without the identification 
of strongly connected components. 

Theorem 1: Let M a Timed Moore Automaton. Then 


(M } livelockFree) = (M H “EF (—-EF(stable))) 


Proof. Consider a live-lock state o9 with property oo = 
EG(Astable). Then sọ Æ stable, so, according to 
Lemma 1, it only has one successor state which is again 
transient. Repeating this argument for all states on the path 
p globally satisfying —stable implies that p is in fact the 
only path starting at og. We conclude that for TMA the 
equivalence 


(o | EG(-stable)) = (o | AG(-stable)) 


holds. Therefore the existence of a live-lock can be identified 
by EF(AG(-stable)), or, equivalently, EF (~EF (stable)). 
As a consequence the absence of live-locks is just the 
negation of the latter formula, that is, =EF(~EF (stable)). 


V. TEST DATA GENERATION 


Kripke structures may be utilized to construct test cases 
according to several test strategies. In this approach, con- 
struction of test cases consists of selecting a path to a system 
state to be tested within a Kripke structure and refining 
this path into sequences of input assignments and output 
assertions. 

Given a system state 0 € S within a Kripke structure 
K(M), we need to find a path p starting in some initial 
state oo € So, containing o and ending in the next possible 
stable system state o’ € S with o’ |} stable. The stability 
of o’ is required in order to be able to check the SUT with 


respect to correctness of the outputs produced and — for 
grey-box or white-box testing — some aspects of its internal 
state. Path p and initial state op are found by performing a 
backward breadth-first search through the Kripke structure 
starting in a. If ø is stable itself, we use it as final system 
state of our test path since its outputs may be asserted during 
execution. If o is a transient system state, we determine 
the next stable system state o’ and the corresponding path 
from ø to it by following transition relation T starting from 
a. Since Timed Moore Automata are deterministic while 
passing through transient states, only one such o’ can exist. 
Observe that these considerations already require M to be 
live-lock free. 

The resulting path p may then be refined into a test case 
by (1) constructing input assignments to produce initial state 
do, (2) asserting stable outputs according to each stable 
system state along the path, and (3) constructing new input 
assignments according to each respective successor system 
state to each stable system state along the path. (1) and 
(3) will then enforce the execution of the selected path, (2) 
verifies the consistency of implementation and specification. 


A. Statement coverage 


In order to attain complete statement coverage, it is 
sufficient to construct test cases covering all locations of 
a given automaton. Since all assignments to outputs must 
occur within entry actions of automaton locations, transition 
coverage is not necessary for statement coverage. For each 
reachable location £ € LOC, we find a corresponding 
state o in Kripke structure K(M), such that o } £2. As 
described above, o gives rise to a test path p through 
K(M) and subsequently to a test case visiting location 
£. When constructing a test case to cover all statements 
executed within a given location, it is preferable to force 
the automaton to stabilize in that location in order to be 
able to assert the effect of all statements within that location. 
Hence it is advisable to find system states, where the stronger 
property o — (ZA stable) holds. Note that it is not necessary 
to explicitly require all transitions leaving the location under 
consideration to be disabled since this is implicitly ensured 
by stable. 


B. Decision coverage 


For TMA, decision coverage can be achieved by (1) con- 
structing test cases to cover all transitions between locations 
and (2) constructing test cases enforcing stable states for 
each location l by setting the inputs appropriately, as long 
as states øo with o(¢) = l are not transient for every possible 
input vector. (1) will cover all control structures, that cause 
locations to change, (2) is needed to negate all such control 
structures. Combined, (1) and (2) will therefore cause all 
control conditions to evaluate to true and false at least once. 
As described above, (2) can be achieved by finding system 
states o for each location l, such that M,o = lA stable. 


To accomplish (1), we need to find a transient system 
state ø € S for any given transition emanating from a 
location £, such that ø enables the transition and disables 
all other outgoing transitions with better priorities. Consider, 
for example, transitions (loc, + {1 > ({a}, {c}, locg),2 > 
({a}, {b}, loc2)}) € T from Figure 1. In order to construct 
a test case covering the transition with priority 2, we need 
to find a system state o, such that: 


o FE loci Ama Anc Ab 


C. Modified condition / decision coverage 


When constructing test cases according to modified con- 
dition / decision coverage criteria, we may again take test 
cases constructed for transition coverage as a basis. For each 
transition between locations, it remains to be shown by test 
cases that each atomic guard condition associated with a 
transition can cause the overall complex guard condition 
to evaluate to false. Since a complex guard condition is 
merely a conjunction of atomic guard conditions, we require 
test cases, where input valuations fulfill all but one atomic 
condition of a given transition. For each location 1 € LOC 
and transition priority n € dom R(l) consider the pair 
(ng,g) E NG x G, (ng, 9) = ™(R(1)(n) formalizing the 
guard condition of the transition with priority n emanating 
from location l. We now require a set of modified guard 
conditions, where precisely one Boolean atom has been 
inverted. The set of guard conditions, where one negated 
Boolean atom from original guard condition (ng, g) has been 
changed to positive polarity is given as: 


GUARD? (1,n) = {(ng',g') € GUARD | 
de € VARin UVARts : 
ng’ = m (RD) (n) — {x}A 
g = m (R0) (n) U {£}} 
Conversely, the set of guard conditions, where one positive 


Boolean atom from original guard condition (ng, g) has been 
changed to negative polarity is given as: 


GUARD (ln) = {(ng’,g') E€ GUARD | 
Jz € VARin UVAR; : 
ng’ =m (RU)(m) U {a} 
g = ™m(R(D)(n) — {2}} 
Finally, the set of relevant guard conditions for achieving 


modified condition / decision coverage for given location | 
and priority n is: 


GUARD meac(l,n) = GUARD? (l, n) U GUARD (l, n) 


For each guard condition ({ngi,..-,N9m}, {91;---;9n}) € 
GUARD meac(l,n), we now require an additional test case 
by finding a transient system state ø with: 


M,o — lA -7stableA 
angi A... A\7NgGmA 
giN..-AGn 


It is irrelevant, whether such a ø leads to a transient or stable 
successor state, since for each test case corresponding to a 
transition to be disabled, either taking another transition or 
stabilizing in the current location is adequate proof of the 
effect an inverted guard condition has. 

Consider transitions (loc; {1+ ({c}, {a}, locz), 2 => 
({b}, {a}, loc2)}) € R from figure 1 and priority 
1. When constructing test cases for modified condi- 
tion / decision coverage for this transition, we construct 
GUARD medc(loci, 1): 


GUARD? (loci, 1) = {(0, {a, c})} 
GUARD (loc,,1) = {({a, c}, 0)} 
GUARD meac(loci, 1) = {(0, {a, ch), ({a, c}, 0)} 


The resulting test cases are then constructed by finding 
system states cı and o2 with properties: 


M,o1 = loc, A astable ^a Ac 
M, 02 = loc, A astable A sa ^ ac 


VI. TEST DATA GENERATION USING SAT SOLVING 


In this section an alternative to the test generation methods 
described above is presented: Based on the abstract syn- 
tax representation of the TMA model, test cases may be 
identified as paths through the model, together with logical 
constraints ensuring that these paths will really be executed. 
Checking that the constraints can be solved — that is, the test 
case is feasible — and generating test data from the concrete 
constraint solutions represents a SAT solving problem which 
we handle using the MiniSAT tool [4]. 


A. General behavior 


We formalize a trace through a TMA as a sequence of 
trace transitions. The set of trace transitions TT C (LOC x 
N) consists of tuples (1,n) € TT of a source location l 
and the transition priority n of a transition emanating from 
that source location. Given trace € TT”, test data for a test 
case executing that trace consists of a sequence of inputs 
inputs € (Sin X Uts)* to be assigned in each test step and 
a corresponding sequence of output outputs € (Sout X Nta)* 
to be asserted within each test step. 

Recall that during execution of TMA some visited loca- 
tions may be part of a transient system state. This means 
that a test trace may need to be partitioned into sub-traces 
corresponding to test steps. Each sub-trace will then end 
in a stable state where correct output valuations may be 
asserted and new inputs may be assigned. The function 
generate TestData (Fig. 6) implements the general behavior 
of the test data generation for TMA. It receives a test trace 
as an input parameter and returns a boolean value indicating 
whether the given test trace is feasible. If feasible, additional 
output parameters will yield input and output assignments 
corresponding to single test steps. 

At the core of this function, a loop iteratively partitions 
the given test trace into test steps. This is accomplished 


function generateTestData(in trace : TT*, 
out inputs : 
(Sin x Bia)”, 
out outputs : 
(Sout X Nts)*) : B 


feasible = true; 


inputs =<>; 
outputs =<>; 
o = 00; 


while( feasible and not empty(trace)) do 
(Zin X Lea) (Fins Tta); 
feasible = nextStep(trace, 
T, 
(Cin: Tts)); 
if (feasible) then 
push_back(inputs, (Tin, ots)); 
let o = (loc, Oin, Ots, Oout, Ota); 


Cin = Fini Ots = Oras 
interpret(o); 
push_back(outputs, (Cout, Cta)); 
endif 
enddo 
return feasible; 
end 
Figure 6. Function generateTestData constructs input and output 


sequences for a given trace. 


by function nextStep (Fig. 8). Each invocation of this 
function determines, whether another test step along the 
given test trace is feasible. If so, it returns the inputs 
(aln, Cis) necessary to realize the shortest such test step as 
well as the remaining postfix of the given test trace trace, 
for which additional test steps need to be generated. While 
test steps along the given test trace are feasible, the loop 
keeps track of current locations as well as current input 
and output valuations. On the one hand, this is necessary to 
provide the needed inputs to nextStep, on the other hand 
this will determine the outputs to be asserted after each 
test step. Bookkeeping of current locations and variable 
valuations is accomplished using a concrete interpretation 
function interpret (Fig. 7), which will compute the next 
stable successor system state for a given running source 
system state. The test data generation will only return valid 
test data, if a given test trace can be completely partitioned 
into feasible test steps. 


B. Concrete interpretation 


The concrete interpreter function interpret : S — S 
for Timed Moore automata can be implemented using the 
operational semantics given in chapter II. Given a source 
system state o € S, such a concrete interpreter function 
will compute the next stable system state and modify the 


procedure interpret(inout o : S) 
let o = (loc, Cin, Cts, Touts Cta); 
Sout = Cout ® (stable + false) 
while(dour(stable) = false) do 

S = {o' € S| T(a,0')} 
select o’ € S” 
ag=a' 
enddo 
end 


Figure 7. Procedure interpret performs concrete interpretation starting 
from a given system state o. 


system state accordingly: given the source system state 
o = (loc, Cin, Ots, Tout; Cta), the interpreter function will 
initially ensure, that the automaton is in a transient state 
by overloading Cout(stable) to be false. Once in a tran- 
sient state, the interpretation will loop while the automaton 
transitions. Within each loop, the set of successor states is 
calculated using T. A successor state is then selected from 
that set, which will become the new source state for the 
next loop execution. According to Lemma | the set S’ will 
always contain exactly one element and the selection of an 
element from that set is not arbitrary. 


C. Test trace partitioning 


Given a system state (loc, Cin, Ots, Tout, Ota) E S and a 
test trace trace E€ TT* starting in location loc € LOC, the 
function nextStep (Fig. 8) calculates the shortest feasible 
prefix test trace that ends in a location with a stable system 
state. In order to accomplish this, an initially empty sequence 
of trace transitions is iteratively expanded along the given 
test trace. This sequence is a feasible test step prefix trace 
if inputs can be constructed, which enforce the trace and 
cause the final location of the trace to be reached as part of 
a stable system state. However, if no location along the given 
test trace can be made stable, but inputs can be found that 
enforce the entire trace, the entire trace may be viewed as 
a feasible test step. Since the entire test trace is covered by 
such a test step, it is irrelevant with respect to the generation 
of input assignments which location becomes stable next. 

Within function nextStep (Fig. 8), sequence step is the 
test step currently under consideration. Within a loop, it 
is expanded using trace transitions from the given test 
trace trace. The loop continues while no feasible test step 
could be found and while there are still trace transitions 
remaining within the given test trace. For each test step 
under consideration, function Cpre fiz constructs a boolean 
constraint expression over input values. If a solution to that 
constraint can be found, the corresponding inputs will (1) 
enable all transitions along the test step, (2) disable all 
transitions with better priorities deviating from the test step, 
and (3) disable all transitions leaving the final location of the 


function nextStep(inout trace : TT, 
ino: S, 


out (Fin, ts) 


: (Sin X Hes) : 


sat = false; 
step =<>; 
remain = trace; 
while(not sat and not empty(remain)) do 
trans = pop_front(remain); 
push_back(step, trans); 
constraint = Cpre fix (o, step); 
if (solve(constraint)) then 
sat = true; 
(Tin Cis) = solution(constraint); 
trace = remain; 
endif 
enddo 
if(not sat) then 
constraint = cryi(o, step); 
if (solve(constraint)) then 


sat = true; 
a $: i K 
dl, = solution(constraint); 
trace =<>; 
endif 
endif 
return sat; 
end 
Figure 8. Function neatStep partitions a test trace into test steps. 


test step in order to make it stable. If no such test step exists 
and the loop terminates unsuccessfully, function cfun will 
construct a boolean constraint expression, which will only 
(1) enable all transitions along the entire trace and (2) disable 
all transitions with better priorities deviating from the entire 
trace. A solution to this constraint will still yield valid test 
data since the entire test trace is covered. Calls of solve and 
solution with a given constraint correspond to invocations 
of the underlying SAT-solver and yield satisfiability and 
satisfying valuations respectively. 


VII. PERFORMANCE RESULTS 


Table I shows performance results for a collection of TMA 
used as specifications of a “real-world” industrial railway 
control application. Within table I, each row corresponds 
to results gathered during model checking and test data 
generation for a single TMA. Column labels (1) #L, (2) 
#T, (3) #IN, (4) #TM, (5) #S, (6) tks, (7) tmc, (8) #TC 
and (9) trc denote (1) number of locations within the 
TMA, (2) number of transitions in the TMA, (3) number 
of inputs, (4) number of timers, (5) number of Kripke states 
within the corresponding Kripke structure, (6) time required 
to construct Kripke structure in milliseconds, (7) time re- 


Table I 
PERFORMANCE RESULTS 


#L | #T | #IN | #M || #S txs | tuc || #1C | tro 
12] 34]5 0 310 |] <1 |<1 7] 28 | <1 
12 | 37 17 0 501 | 10 <1 V29 | 20 
12 | 38 | 7 0 442 | 10 <1 || 28 | 60 
13 | 35/8 0 1071 | 20 20 35 | 20 
16 | 28/8 I 756 | 10 10 27 |20 
18 | 29 | 6 2 574 | 10 10 27 10 
1s | 41 | 10 | 0 1485 | 40 20 38 |50 
19 | 28 | 4 4 306 | <1 | <1 24 | 10 
19 | 34 |7 0 201 | <1 | 10 33 T20 
22 |38 | 10 3 513 | 10 10 37 10 
22 | 40 | 5 0 455 | <1 |<1 [31 10 
24 |54 |14 | 2 1613 | 30 30 43 |30 
25 173 | 8 3 5095 | 120 | 310 |] 63 | 40 
33 | 48 | 9 5 3090 | 50 110 |) 43. | 20 


quired to perform model checking for livelocks on Kripke 
structure in milliseconds, (8) number of generated test cases 
ensuring complete transition coverage and (9) time required 
to construct test cases using the SAT-based approach in 
milliseconds respectively. All measurements were performed 
on a standard 2.0 GHz Intel®Core™2 Duo processor with 
2 GB of RAM. Note that for some TMA the corresponding 
Kripke structures were constructed within less than a single 
millisecond. The construction of Kripke structures never 
took more than 120 milliseconds to complete. All Kripke 
structures were sufficiently small to easily fit into RAM. 
Examining Kripke structures to detect livelocks was always 
completed within at most 310 milliseconds, many TMA 
could be checked within less than a single millisecond. 
Since no TMA contained livelocks (all livelocks detected 
in previous TMA specification versions had been removed) 
and since therefore all constructed Kripke states had to 
be examined, the time measurements constitute worst-case 
scenarios. 


VIII. CONCLUSION 


We have introduced the Timed Moore Automata formal- 
ism which is used for specification and semi-automated 
model-based code generation of cooperating software com- 
ponents in railway control systems. An operational seman- 
tics for TMA and algorithms for checking these models 
against livelocks and for automated generation of test cases 
and associated test data have been presented. Livelock 
checking and one variant of test generation algorithms were 
based on Kripke structures as used in explicit model check- 
ing. Apart from the fact that, due to the moderate size of the 
unit specification models, explicit models are acceptable for 
our railway control application context, there is another rea- 
son for utilizing explicit Kripke structures in test automation: 
When generating test data for models M designed in more 
general formalisms admitting large data types like 32, 64 
and 128 bit integers and floating point numbers, arithmetic 


conditions and assignments involving arithmetic expressions 
are abstracted to Boolean atoms. This abstraction induces 
a model A(M) simulating the original model M. Kripke 
structures over (M) can be readily exploited to identify 
classes for equivalence testing: Roughly speaking, different 
concrete paths through M being abstracted to the same path 
through A(M) represent members of the same equivalence 
class, and therefore it often suffices to test only one or a 
small number of them. 

The test automation techniques described here have been 
applied in numerous test suites performed by Verified Sys- 
tems International GmbH for the verification of railway 
control software of highest criticality level SIL-4 according 
to the international standard [2]. Compared to conventional 
unit tests performed before, our techniques reduce the effort 
by approx. 90%. This extraordinary efficiency improvement 
could be gained since the TMA models are already provided 
by the development teams. In other testing campaigns, where 
testing models had to be elaborated before being able to 
benefit from the automation capabilities, the efficiency im- 
provement was approx. 30% when compared to conventional 
test campaigns. 
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